home *** CD-ROM | disk | FTP | other *** search
/ CU Amiga Super CD-ROM 2 / CU Amiga Magazine's Super CD-ROM 02 (1996)(EMAP Images)(GB)[!][issue 1996-04].iso / magazine / amiga_e / amigae.june.archive / 000114_crash!kirk.safb.af.mil!BWILLS_Mon, 21 Jun 93 10:27:10 PST.msg < prev    next >
Text File  |  1993-08-31  |  3KB  |  64 lines
  1. Received: by bkhouse.cts.com (V1.16/Amiga)
  2.     id AA00000; Mon, 21 Jun 93 10:27:10 PST
  3. Received: from kirk.safb.af.mil by crash.cts.com with smtp
  4.     (Smail3.1.28.1 #15) id m0o6nUW-0000IDC; Fri, 18 Jun 93 13:56 PDT
  5. Message-Id: <m0o6nUW-0000IDC@crash.cts.com>
  6. Date: 18 Jun 93 15:54:00 CST
  7. From: "Barry D. Wills" <BWILLS@kirk.safb.af.mil>
  8. To: "amigae" <amigae@bkhouse.cts.com>
  9. Subject: arpbase.m and asl.m
  10.  
  11. To Son Le and Wouter.
  12.  
  13. It has been said:
  14.  
  15. > >> think it'd hurt too much as the '.i' files contain pretty much the same th
  16. > >> , just look at dosasl.i, anyhow if you'renot gonna officially support it h
  17. > >> about putting a LABEL directive in the modules. It's kinda standard to use
  18. > >> anchor.buf for the filename, if you have to use anchor+SIZEOF anchorpath,
  19. > >> it makes E a bit more primitive to use.
  20. >  
  21. > E, is a higher programming language, and it simply doesn't allow
  22. > for these labels like assembly. if you really want, then just change
  23. > 
  24. > LABEL ap_buf
  25. >  
  26. > in the .i file to 
  27. >  
  28. > STRUCT ap_buf,1
  29. >  
  30. > and convert with the original version of Iconvert. You'll get exactly
  31. > the same thing as in C (see: dosasl.h), and it will let you address
  32. > with "anchor.buf"
  33. > but: don't go about changing thing which might affect compiler
  34. > behaviour like you did before. my warning should be enough.
  35. >
  36. > >> >...non-standard extension to the language... the fact that EC accepts your
  37. > >> >arrays of length 0 is pure luck...
  38. > >> 
  39. > >> Wouter, let me make sure we understand each other.  I assume you looked at
  40. >  
  41. > >> arpbase.i include.  I was under the impression that this LABEL ap_Buf was 
  42. > >> *supposed* to be part of the STRUCTURE AnchorPath!  Are you saying it is not
  43. >  
  44. > just look at the C version... the assembly one is just a hack.
  45.  
  46. I tried to keep this pertinent, and retain some continuity.  I think I'm
  47. keeping up, so correct me if I'm wrong.
  48.  
  49. 1.  To use ap_Buf in assembly, I must allocate a variable of type AnchorPath to
  50. be (SIZEOF AnchorPath + SIZEOF buffer_i_wanna_use).
  51.  
  52. 2.  To use ap_Buf in C, I must allocate the same way. The confusing thing is 
  53. that C requires the struct to reserve a UBYTE variable of size 1 in order to 
  54. keep the label ap_Buf, whereas assembly only requires the definition of a label.
  55.  
  56. 3.  In E I must allocate the same way.  But if I use the libraries/asl.m module
  57. I won't be able to access the buffer by saying myAnchorPath.ap_buf.  To access
  58. this I need to say my_ap_buf := myAnchorPath + SIZEOF_anchorPath (or something
  59. like that.)
  60.  
  61. Any comments?
  62.  
  63. -- Barry
  64.